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Background 

This invention relates generally to object oriented 
software technologies and particularly to software objects 
which are binary compatible. 
5 ActiveX controls are a subset of the COM object 

oriented software technology. COM can use a variety of 
different object oriented program languages such as C++, 
Java and Visual Basic. ActiveX controls are typically 
plugged into a control container which is a type of client. 

10 The ActiveX controls self -register on a computer in 

a database. In Windows®-based platforms, the database is 
called a registry. The registry provides a way for a 
control to advise the client about the control's 
functionality. More specifically, the ActiveX control 

15 places keys in the registry or database to let the container 
know its functionality. The registry includes information 
which identifies a particular control or object including 
Globally Unique Identifiers (GUIDs) , Category Identifiers 
(CATIDs) , and Class Identifiers (CLSIDs) . 

20 A layer class, wrapper or interface definition is a 

source code level version of a COM object. It provides an 
interface between the container or client and the object 
which may be an ActiveX control. Additional controls may be 
inserted, snapped in or "plugged in" to a container that 

25 already has one or more controls. A plug- in control is 
source compatible if a new version of the control works 
unchanged in a container application but the user program 
must be rebuilt. That is, the application program must be 
recompiled and then the application can be run without 

3 0 further change. 

With a "binary compatible" control, a new version 
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can be plugged into an existing application that was 
designed and built for the old version. However, the 
conventional wisdom in the field is that the plug- in must 
appear to the container as if it were the old version in 
5 order for the plug- in to be binary compatible. That is, the 
plug- in must support the old CLSID and all interfaces 
exactly as they were (that is, with the same IIDs, names, 
dispids, parameters and so forth) . See Denning, Adam, 
"ActiveX Controls Inside Out", Microsoft Press (1997), p. 

10 131. Thus, the conventional wisdom holds that in order to 
be binary compatible, the same identifiers and interfaces 
must be used for the plug- in. 

A GUID is conventionally hard coded into a layer 
class. Other objects can then be used with a given 

15 container; however, they must have the same interface and 
GUID in order to work with the layer class in a binary 
compatible fashion. 

Thus, there is a continuing need to enable objects, 
with different interfaces and/or different GUIDs, to snap in 

20 to a container or client environment. 

Summary 

In accordance with one aspect of the present 
invention, a method for object oriented programming includes 

25 creating a first object, having a first identifier 

associated with a first client. Thereafter, a second object 
having a second identifier is inserted, such that the second 
object is associated with the first client. Even though the 
first and second identifiers are different, the second 

30 object is used with the first client, without recompiling. 
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Brief Description of the Drawings 
Fig. 1 is a high level flow diagram in accordance 
with one aspect of the present invention; 

Fig. 2 is a more detailed flow chart for 
5 implementing a flow in accordance with Fig. 1; and 

Fig. 3 is a conceptual depiction of an approach to 
object oriented programming. 

Detailed Description 

10 Referring to Fig. 1, a method for object oriented 

programming may be implemented in any object oriented 
programming technology including COM, ActiveX, Java, Visual 
Basic, C++ and the like. As indicated in block 10, a first 
object with a first GUID is registered on the system. Then 

15 a second object with a second GUID may be registered as 

indicated in block 12 . Time may pass between the first and 
second registrations. The registration may be done in any 
conventional database for registering objects including the 
so-called registry utilized in Windows®-based platforms. 

20 As indicated in block 14, it is thereafter possible 

to selectively access one of the first and second objects 
using the same client or container despite the fact that the 
objects have different GUIDs . In addition, these first and 
second objects may be accessed using the same container or 

25 client despite the fact that they have different interfaces, 
for example, in connection with COM based objects. Of 
course, the dispids and parameters for the two objects still 
would be the same. However, the first object or the second 
object may be selectively accessed after snapping in the 

3 0 second object. 

In this way, a truly binary compatible object system 
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may be developed in which a second object may be snapped 
into a container or client containing a first object and the 
second object may be utilized without recompiling. No 
recompiling is necessary even though the first and second 
5 objects have different GUIDs and even if the first and 
second objects have different interfaces, for example, in 
the case of COM applications. 

While these techniques are applicable to a variety 
of technologies, they are particularly applicable to ActiveX 

10 controls wherein first and second controls may be snapped 
into a container. In this way the container can selectively 
access either the first or the second object without 
recompiling. In applications using a layer class or 
wrapper, the layer class may then be associated with more 

15 than one object. A new ActiveX control can be snapped in 
without creating a new layer class each time, which would 
require recompiling. 

Referring now to Fig. 2, a more detailed flow chart 
for implementing the technology of Fig. 1 in COM technology 

20 begins with block 16. At block 16, each object for a given 
client or container is registered. At block 18, a layer 
class is appropriately programmed (using the SetGUID and 
GetGUID methods described below) to enable the GUIDs for any 
of the registered objects to be selected. Thereafter, it is 

25 then possible to access either object despite the fact that 
the second object that is snapped in may have a different 
GUID than the first object. In connection with applications 
involving ActiveX controls using dynamic linked libraries or 
DLLs, the registration is normally accomplished using the 

30 DllRegisterServer ( ) method in Windows®-based applications. 
In non-ActiveX applications when DLLs are not used, the 
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registration may be done with EXEs . In this way, the GUIDs 
of the respective objects are registered in a database (or 
in Windows® applications, at the registry) . 

SetGUID and Get GUI D methods are implemented in an 
5 application involving a layer class. GetGUID, which is part 
of the layer class, provides the GUID that is set when the 
layer class calls for its own GUID. The SetGUID method, 
which is part of the layer class, sets the GUID in the layer 
class for the desired object, as shown at block 22. Thus, 

10 SetGUID sets the new GUID in the layer class and GetGUID 
returns the GUID from the database. 

In alternative embodiments it is possible to use the 
CoCreatelnstance method to send in the GUID of the second 
object when that object is referenced. The GUID of the 

15 second object is sent in for the snapped in second object 
and the same interface definition may be utilized for both 
objects. In this case, the SetGUID and the GetGUID method 
are unnecessary and manipulation of the layer class is 
likewise unnecessary. 

20 Using either technique, it is possible to 

dynamically create new functions in the future for a given 
client or container. This can be done in a truly binary 
compatible fashion without requiring identifiers to be 
identical or interfaces to be identical, or recompiling. 

25 Referring again to Fig. 2, one can access the first 

object, as indicated in block 24, thereafter obtain the GUID 
for a second object, as indicated in block 26, and set the 
GUID for the second object in place of the GUID for the 
first object, as indicated in block 28. As indicated in 

3 0 block 30, the second object may be accessed by the same 

container or client that previously would have accessed the 
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first object. This is done in a binary compatible fashion 
without recompiling. 

These techniques are applicable, not only to in 
process servers such as DLLs, but also to remote 
5 applications, such as Distributed COMs (DCOMs) . Generally 
the techniques described herein are applicable to any object 
which can be snapped into a container or client situation. 

Referring now to Fig. 3, a pair of objects 32 and 34 
have different GUIDs and different interfaces. The 
10 interface for the object 32 is indicated as II and the GUID 
for object 32 is indicated as GUI DA. Similarly, the GUID 
for object 34 is GUIDB and the interface for object 34 is 
12 . 

The compiled application, indicated within the 
15 dotted line box 36, includes, in the illustrated embodiment, 
a layer class or wrapper 38 and the client or container 46. 

As indicated, the layer class communicates with the client 
46 . 

The layer class 3 8 includes the SetGUID method 42 
20 and the GetGUID method 40. The layer class 38 also stores 
the selected GUID 44. In the illustrated embodiment, the 
selected GUID is the GUI DA as indicated by the arrow between 
the layer class and the object 32. However, the layer class 
can obtain the GUID for the object 34 through the client 
25 from the system database 48. The system database or 
registry includes GUIDs 50 and 52 in the illustrated 
embodiment. Thus, the client can obtain GUIDs for desired 
objects from the system database 4 8 and the layer class can 
access the corresponding object without requiring 
3 0 recompiling. 

In prior systems, the objects 32 and 34 would need 
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to have the same GUIDs and interfaces to enable a binarily 
compatible snap- in system. Now snap- in objects with 
different GUIDs and different interfaces may be used to 
implement new functions as necessary in the future without 
5 recompiling. In this way, a layer class may be created that 
has selectively programmable GUIDs for more than one object. 

With embodiments of the present invention, one can 
extend a current technology by allowing updates and new 
functions. That is, a new object may be used in place of 

10 its predecessor. The new object may also be used 
selectively in conjunction with its predecessor. 

While the present invention has been described with 
respect to a limited number of preferred embodiments, those 
skilled in the art will appreciate numerous modifications 

15 and variations therefrom. For example, while the 

illustrated embodiments illustrate a COM or ActiveX controls 



application, those skilled in the art will appreciate that 
similar approaches can be used in other programming 
technologies and languages. It is intended that the 
20 appended claims cover all such modifications and variations 
as fall within the true spirit and scope of the present 
invention. 

What is claimed is: 
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